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QCDml: First milestone for building an International Lattice Data Grid 

CM. Maynard'', D. Pleiter'^, 

'"School of Physics, University of Edinburgh, Edinburgh EH9 3JZ, UK 

^John von Neumann Institute NIC / DESY Zeuthen, D-15738 Zeuthen, Germany 

We present an XML schema for marking up gauge configurations called QCDml. We discuss the general 
principles and include a tutorial for how to use the schema. 
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1. REPORT FROM THE METADATA 
WORKING GROUP 

To achieve ILDG's aim of sharing gauge field 
configurations world-wide a standardised descrip- 
tion of configurations is mandatory. XML (Ex- 
tensible Markup Language) is the language of 
choice for metadata since it is designed to de- 
scribe data. These metadata documents will be 
both human readable, since XML is verbose, and 
easy to parse by computers. Finally, standards 
on the structure and contents of XML documents 
can be enforced by using XML schemata.^ 

The ILDG metadata working group P ad- 
dressed in recent years the task of defining an 
XML schema. During the 2003 lattice con- 
ference [2j the group presented an initial pro- 
posal. Since then the strategy for marking-up the 
physics parameters has been revised. However, 
whilst the contents remained unchanged, the us- 
ability has been significantly improved. The 
working group presented at this conference the 
first working version of the schema, QCDml. 

Many lattice practitioners, who are typically 
not familiar using XML yet, might ask whether 
the proposed strategy is too complicated. How- 
ever, using XML is much easier than many might 
expect. A large number of software tools exists 
for creating and parsing XML documents. When 
looking at the proposed schema, it should be re- 
alised that it's complexity originates from the 
large variety of different simulations being carried 
out within the lattice community. Metadata doc- 
uments will only contain information on one par- 
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ticular simulation. All metadata documents will 
have to conform to the schema. It is the schema 
which contains the complexity which allows the 
many different actions being used for simulating 
QCD with dynamical fermions. 

During the design process three general re- 
quirements have been taken into account. Firstly, 
the schema has to be extensible as parameters of 
future simulations cannot be anticipated. This 
has to be done in such a way that any metadata 
document which conforms to the current schema 
will also conform to any future extended schema. 
The long-term validity of all metadata documents 
published by users of ILDG is a definite design 
goal of the schema. Secondly, the mark-up of sim- 
ulation parameters has to be unique to avoid, e.g., 
the same action being described in two different 
ways. This would otherwise spoil the possibility 
to search for certain configurations. Finally, the 
schema has been kept general enough to allow 
the description of data other than gauge config- 
urations (propagators, correlators, etc.) in the 
future. 

1.1. Overview on the xml schemata 

Gauge configurations are generated by a 
Markov chain. All configurations from one chain 
share many properties. Therefore the metadata 
can be split into two documents. The ensem- 
ble XML document contains all parameters which 
remain unchanged for the whole Markov chain. 
Other parameters are specific to one or a set 
of consecutive Markov steps and will be stored 
in a configuration XML document. A Universal 
Resource Indicator (URI) is used to link these 
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two documents as well as the Logical File Name 
(LFN) to link the configuration XML document 
and the gauge configuration itself (see Fig. 
For both types of XML documents correspond- 
ing schemata have been developed which can 
be downloaded from the working group's web- 
site [3. 



Ensemble XML ) ) Ensemble URI 




Figure 1. Logical file names (LFN) and URIs link- 
ing ensemble and configuration XML documents 
as well as gauge configurations. 

An example for parameters which will be the 
same for all configurations of an ensemble are the 
physics parameters. The corresponding parts of 
the ensemble XML document consists of infor- 
mation about the lattice size and a mark-up of 
the action. The description of the action is most 
critical for preserving uniqueness and extensibil- 
ity of the schema. The metadata working group 
adopted the following strategy which is visualised 
in Fig. El 

• Each action can be split into a gauge and a 
fermion action. 

• The ensemble XML schema contains an 
element <generalGluonAction> and an 
optional element <generalQuarkAction> 
which will substituted by the actually used 
action. 

• Actions which contain a structure which is 
the same as for a simpler action are ordered 
by an inheritance tree. For example, the 
clover fermion action is equivalent to the 
standard Wilson fermion action plus an im- 
provement term. 



• Actions which have the same structure in 
common are grouped. For instance, the 
Iwasaki and the Symanzik improved gauge 
actions only differ by the choice of the cou- 
plings. 

This inheritance tree of possible actions is obvi- 
ously extensible. Any action will be included into 
the schema only once to ensure uniqueness. 
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Figure 2. Hierarchy of actions in the ensemble 
XML schema. 

The description of each action is organised in 
three parts (See Fig. EJ. Firstly, an array of 
<couplings> allows to store the names and val- 
ues of all couplings and, in case of the fermion ac- 
tion, the number of flavours. Secondly, a descrip- 
tion of the fields is required to store information, 
e.g., about the used normalisation or boundary 
conditions. Finally, any further information can 
be stored in a glossary. 

The element <glossary> contains a URL to 
a document provided by the contributors. This 
document does not have to conform to any 
schema, it may even be not an XML but rather a 
human readable document, e.g. a TeX file. This 
gives the contributors the freedom to store all 
kind of information with regard to the used ac- 
tion, for instance information on the particular 
choice of couplings. Nevertheless, some guidelines 
will be needed to ensure that these documents 
contain all relevant information in a comprehen- 
sive form. 



3 



The variety of algorithms being used in lat- 
tice simulations is even larger than the number 
of different actions. The parameters of the al- 
gorithms are therefore essentially unconstrained. 
It should be noted that as a consequence such 
parameters are in practise not searchable. The 
only constrained element <exact> provides infor- 
mation on whether the algorithm being used is 
exact or not. 

It will be mandatory to provide a reference to 
a publication on the used algorithm and an URL 
to a glossary document. Furthermore, all submit- 
ters are strongly encouraged to provide a full list 
of all algorithmic parameters used in their simu- 
lations. The names of the parameters should be 
chosen in such a way that they can be uniquely re- 
lated with the algorithmic parameters described 
in the publication and the glossary file. Unlike 
the physics parameters the algorithmic param- 
eters might change when generating a Markov 
chain. For instance, the step size of the HMC 
algorithm might be adjusted during a run. While 
the ensemble XML document will contain most of 
the information on the used algorithm, the sub- 
mitter can store those parameters which might 
change within an ensemble into the configuration 
XML document. 

As an matter of good scientific research 
practise, the generation of each configuration 
should be fully and comprehensively documented. 
Therefore submitters will have to provide infor- 
mation which machine and what code has been 
used to generate a particular configuration. Each 
machine can be identified by machine (or parti- 
tion) name, the hosting institution and the ma- 
chine type. Additional information can be stored 
as an optional comment. Concerning the sim- 
ulation program submitters have to ensure that 
it can be identified by a name, a version string 
(e.g. a CVS tag), and the date of compilation. 
Again an optional comment allows to add fur- 
ther information, e.g. on compile time variables. 
All these parameters are not constrained and 
therefore not searchable. Only the information 
on the precision used to generate configurations 
will be searchable, as users might care about the 
used machine precision, in particular when quark 
masses become light. 



The metadata will also include information 
about who submitted a configuration to ILDG 
within which project. This information can be 
stored in the management section which is fore- 
seen in both the ensemble and the configuration 
XML document. Within this section also infor- 
mation will be stored which allows the user of a 
configuration to check the integrity of the down- 
loaded data. To do so he can verify the checksum 
for the binary files, which will however not be pre- 
served when transforming the gauge configuration 
into a different format. The user can still perform 
another test by recalculating the plaquette value 
and comparing this with the value stored in the 
configuration XML document. It should however 
be noticed that this test is less strong as both val- 
ues will only agree within rounding errors and be- 
cause the plaquette value is preserved by various 
transformations of a gauge field configuration. 

All operations affecting an ensemble or just a 
particular configuration should be documented. 
Possible actions include the insertion and modifi- 
cation of an ensemble and the insertion, replace- 
ment or even the revocation of a configuration. 
The last two actions might be necessary if for ex- 
ample the computer or the code which was used 
to generate a configuration turned out to be bro- 
ken. It should be noted that the submitters of 
configurations might not have to generate this in- 
formation themselves, as the user interfaces to be 
developed for performing such actions could take 
care of patching the ensemble and configuration 
XML documents accordingly. 

2. QCDML TUTORIAL 

The purpose of this section is to demonstrate 
how to mark up configurations according to the 
XML schema QCDml. We start with some 
Frequently Asked Questions (FAQ) about XML 
schema. 

2.1. XML Schema FAQ 
• What is XML Schema? 

— XML schema is a collection of rules for 
XML documents 

— An XML schema is itself an XML in- 
stance Document (ID) 
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• Why do we need an XML schema? 

— So that computers can read and un- 
derstand XML IDs 

— e.g. <length>16</length> 

— The meaning of length is context de- 
pendent, the schema makes this infor- 
mation exphcit 

• Do users need to learn XML schema? 

— No. XML schema makes it easier to 
write XML IDs 

2.2. Getting started 

QCDmll.l is available for use and can be down- 
loaded along with documentation and example 
XML IDs from the ILDG website by following 
the links in the metadata section. In QCDmll.l 
the metadata is split into two parts. Metadata 
which is common to all configurations in an en- 
semble lives in the namespace of the ensemble, 
and only one XML ID for the whole ensemble is 
required. 

An XML namespace is defined by W3C con- 
sortium as a collection of names identified with 
a URI reference. Metadata which is specific to 
each configuration lives in a separate namespace 
and an XML ID is required for each configura- 
tion. Below is an XML chunk, it is the start of 
an example QCDml ID. 

<?xml version="1.0" encoding="UTF-8"?> 

<niarkovChain xmlns= "http : / / www . Iqcd . org/ 

#ildg/qCDml/ensemblel .1" 

xmlns : xsi="http : //www. w3 . org/2001/ 

#XMLSchema-instance" 

xsi : schemaLocatioii="http : //www. Iqcd. org/ 

#ildg/QCDml/ensemblel . 1 

#www . ph . ed . ac. uk/ukqcd/ community/ 

#the_grid/QCDmll.l/ 

#QCDmll . lEnsemble.xsd"> 

<marko vChainURI > 
www . Iqcd . org/ ildg/ukqcd/ukqcdl 

< /marko vChainURI > 

+<management/> 

+<physics/> 

+<algorithm/> 
</ marko vChain> 



The symbol is used to show that there is 
substructure below the element, and the # symbol 
is used to indicate line continuation. The element 
<markovChain/> is the root of the XML ID. The 
rest of the first line is the URI which identifies 
the namespace of the ensemble metadata. This 
has no prefix to identify elements which belong 
to this namespace as it is the default namespace. 
The second line is the namespace of XML schema 
itself. The third and fourth lines give the location 
of the file which contains the schema. The at- 
tribute xsi : schemaLocation is used to link the 
URI which identifies the namespaces with a URL 
which is the file which contains the schema. This 
could be a URL which is the URI of the names- 
pace but it doesn't have to be. 

The element <markovChainURI/> which fol- 
lows <markovChain/> is the URI which identifies 
this ensemble. Each configuration XML ID which 
belongs to this ensemble is linked to it using this 
URI. 

If an XML ID conforms to the rules of a partic- 
ular schema it is said to be valid. A software ap- 
plication which verifies that an XML ID is valid is 
unsurprisingly called a validator. Schema aware 
applications can then read and use valid XML 
IDs. One can write XML IDs in an editor such 
as vi or emacs, however, other tools are avail- 
able. XMLspy is commercial software which can 
be used for schema and XML ID manipulation, it 
can, for instance, generate an XML ID from the 
schema. There are many other XML manipula- 
tion tools, links can be found at 

2.3. Physics and Actions 

The element <physics/> contains two ele- 
ments, <size/> and <action/>. The former is 
rather self explanatory and contains the size of 
the system. 

Most searches of metadata will be on the ac- 
tion, consequently a lot of thought has gone into 
marking up the actions. Some of the object ori- 
ented features of XML schema have been em- 
ployed in the schema to categorise actions, such 
as inheritance and the substitution group. This 
enables the XML IDs to be relatively simple. The 
general structure is shown in figure |21 The action 
has been split into two parts, gluon and quark. 
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generalGluonActionType 



gluon [^ 1— ( ■■■ — l^generalGluon Action [^ 1— ( ^-™-^ }E1~ 



The action HML chunk 



- quark 



Has the general properties oF 
the gloun actronj i.e. the gluon 
field and Che glossary XML 



glossary 



- [^gluonField [+ ] 

Contains the properties oF 
the gluon field, e.g. gauge 
group and representation 



couplings | 



I generalQuarkActionType 



1^ generalQuark Action 



Has the general properties oF 
the quark action, i.e. the 
number of quark flavours and 
the properties oF the fields 



glossary 



- [^quarkField [+ ] 



field 
,iid boundary 



couplings 



I 



Figure 3. A diagram of the action in QCDML 



These general elements encapsulate the general 
properties of the actions, such as the fields and 
the glossary document. The glossary contains in- 
formation such as the mathematical definitions 
of the actions and a reference to a paper where 
the action is discussed. However, this type of in- 
formation is not suitable to being marked up in 
XML, it is essentially unconstrained and as such 
is not really searchable by a computer. 

Specific quark and gluons inherit their prop- 
erties from the general actions. These ac- 
tions, such as <wilsonQuarkAction/> have spe- 
cific couplings, in this case <kappa/>. The 
<cloverQuarkAction/> is an extension of this 
action, as it is a Wilson action, but has an extra 
coupling, <cSW/>. This is shown in figure 0] An 
inheritance tree for various actions can be built 
up in this way. 

The metadata working group (MDWG) has not 
set up inheritance trees for all possible actions, 
but the schema is extensible so that further ac- 
tions can be added without existing XML IDs 
having to be modified. Actions that have been 
added to QCDml are shown at the ILDG meta- 
data web pages, and an example of which is shown 
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Figure 4. A diagram of the NP Clover action 
in figure [SI 

For the gauge actions the metadata work- 
ing group adopted a particular convention for 
<sixLinkGluonActions/> 

^61i„k ^ ^ ^ (^^-p _^ ^^j^ ^ ^ ^^^^ 

Where V is the Plaquette Wilson loop, TZ the six- 
link rectangle, C the six-link chair and X the three 
dimensional Wilson loop. The values of some of 
the couplings can be restricted to certain ranges 
or specific values. For example, in the Iwasaki 
RG action, the couplings are constrained, C2 = 
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generalQuarkAction \+ \ 



Has the general properties oF 
the quark actiorij i,e. the 
number of qu^rk flavours and 
rhe properties oFche Fields 



generalGluonAction [+ ] 



Has the general properties oF 
the gloun action^ i.e. the gluon 
Field and the glossary XML 



KSQuarkAction 



The basic KS action, 
Abstract 



plaquetteGluonAction [+ | 



The "Aiilson plaquette action., has 
a coupling beta 



ImprQuedKSQuarkAction ^ 



Improved KS quarii action^ abstract 
as it doesn't fix any oFthe couplings 



asgTadQuarkActiorT^ ' ] DBW2GluonActipn^ 



A specific improved KS quari; 
action 



generalOuerlapQuarkAction 



The abstract OveH^p qustk operator 



siKLinkGluon Action 



Abstract class oF all sIk link 
gluon action. Doesn't Fix the 
couplings. 



D&W2 is a six link action 
with speciFic couplings 



iwasakiRGGIuon Action 



domainWallQuarkAction [+] 



The domain ti\iall quark action. 4D 
is WWzon and the approi is tanh 



This six-link action has three 
couplings 

j tadpoleSymanzikGluonAction [+ ] 

This six-link action is the tadpole improved 
v^ith all Four couplings 



wllsDnQuarkActlon 



The Wilson quahi^ acrion, has 
a coupling kappa 



clQuerQuarkAction [+] 



The generic clovei' Wilson 
action type. H is abstract 
because there are dlFFet^nt 
definitions oF CSW that ane 
all clover actions 

j npClotferQuarkAction [+ | 

The Clover t/^ilson quark action 
where the coefficient has been 
detemnined non-pettutbatively 



Figure 5. A diagram showing the inheritance tree 
for quark and gluon actions. 

C3 = 0, Co = (1 — 8ci) and ci = —0.331. 

The quark action couphng has an integer val- 
ued element <numberOf Flavours/>. This la- 
bels how many flavours have these couplings, 
i.e. how many degenerate flavours. The element 
<couplings/> is array valued, that is this part 
of the action can be repeated but with different 
couplings. This is useful for marking up non- 
degenerate quark flavours. 

An XML chunk for the n/ — 2 non- 
perturbative clover action is shown below. 

<npCloverQuarkAction> 

<glossary> 

www . Iqcd . org/ ildg/ 
#npCloverQuarkAction. xml 

</glossary> 



+<quarkField/> 
<couplings> 

<numberOf Flavour s> 
2 

</numberOf Flavour s> 
<kappa>0 . 1350</kappa> 
<cSW>2.0171</cSW> 
</couplings> 
</npCloverQuarkAction> 

This is quite a short XML chunk, as the hierar- 
chy npCloverQuarkAction — > CloverQuarkAction 

WilsonQuarkAction GeneralQuarkAction is 
contained in the schema. 

A rather technical point is that in the XPath 
1.0 in] specification, there is no support for 
substitution groups which means that a search 
for WilsonQuarkAction elements would not re- 
turn any cloverQuarkAction elements, although 
this can be achieved with a boolean "or" such 
as [/action/quark/npCloverQuarkAction I 
/action/quark/WilsonQuarkAction] . How- 
ever, the specification for XPath 2.0 is nearing 
completion and this issue is beginning to be 
addressed. 

An XML chunk for the n/ = 2 + 1 AsqTad 
Kogut-Susskind quark action is shown below. 

<asqTadQuarkAction> 
<glossary> 

www . Iqcd . org/lqcd/ 
#asqTadQuarkAction .xml 
</glossary> 
+<quarkField/> 
<couplings> 

<number Of Flavour s> 
2 

</number Of Flavour s> 
<mass>0 . 02</mass> 
<cNaik>-0.05713116</cNaik> 
<clLink>0 . 625</clLink> 
<c3Link>-0 . 08569673</c3Link> 
<c5LinkChair> 

0.02937572 
</c5LinkChair> 
<c7LinkTwist> 

-0.006713076 
</ c7LinkTwist> 

<cLepage>-0 . 1175029</cLepage> 
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</ couplings> 
<couplings> 

<numberOf Flavours> 
1 

</numberOf Flavours> 
<mass>0 . 05</mass> 
<cNaik>-0 . 05713116</cNaik> 
<clLink>0 . 625</clLink> 
<c3Link>-0 . 08569673</c3Link> 
<c5LinkChair> 

0.02937572 
</c5LinkChair> 
<c7LinkTwist> 

-0.006713076 
</c7LinkTwist> 

<cLepage>-0 . 1 175029</cLepage> 
</couplings> 
</ asqTadQuarkAction> 

The structure is the same, and all the couplings 
are clearly shown. The non-degenerate quark 
masses result in a second <couplings/> element, 
but with different number of flavours and different 
mass. It is easy to distinguish between n/ = 2 + 1 
and n/ = 3. 

2.4. Management 

This metadata gives the status of the data that 
is registered with the ILDG. In that sense it is cre- 
ated when the data is made public. In principal 
this would be generated or "stamped" by some 
ILDG middleware. As this application docs not 
yet exist, it will have to be generated "by hand" . 
Below is an example of the management chunk of 
XML. 

<management> 

<revisions>l</revisions> 
<collaboration>UKQCD</collaboration> 
<pro j ectName>Clover MF=2</proj ectMame> 
<archiveHistory> 
<elein> 

<revision>l</revision> 
<revisionAction> 
add 

</revisionAction> 
<numberConf igs> 
829 

</numberConf igs> 



<participcint> 

<naine>Ch.ris Maynard</naine> 
<institution> 

University of Edinburgh 
</institution> 
</participcint> 
<date> 

2004-04-04T16 : 20 : lOZ 
</date> 
<confflient> 

This is the time of addition 
</ comment > 
</elem> 
</archiveHistory> 
< /management > 

The <archiveHistory/> element can have 

several revisions. <revision/> is array val- 
ued. An ensemble could have configurations 
added to it, replaced or even removed, if a 
mistake has been found. So the allowed val- 
ues of <revisionAction> are an enumeration of 
{add, remove, replace}. To discover how many 
configurations are in an ensemble, it is relatively 
easy to construct an XPath query to find the 
number of revisions and then the number of con- 
figurations for each revision. 

2.5. Algorithm 

Algorithmic metadata is split between the en- 
semble and configuration documents, as it is pos- 
sible, for instance, to have different stopping re- 
quirements for the inverter across the ensemble. 
The algorithmic metadata is in the form of uncon- 
strained <name/> <value/> pairs. For example 

<algorithm> 

<name>GHMC</name> 
<glossary> 

www . ph . ed . ac. uk/ukqcd/ 
#community/ GHMC . xml 
</glossary> 
<ref erence> 

Phys . Rev . D65 : 054502 , 2002 
</ref erence> 
<exact>true</ exact> 
<parameters> 

<name>stepSize</name> 

<value>0 . 00625</value> 
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</parameters> 
</algoritlim> 

It would be very difficult to create a hierarchi- 
cal structure for algorithms, and especially dif- 
ficult to make such hierarchy extensible. Again 
there is a glossary document which contains the 
free text, or mathematical definition of the algo- 
rithm, and a reference to a paper which describes 
the algorithm. There is also the boolean valued 
element <exact/> which denotes whether or not 
the algorithm is exact. 

2.6. Configuration XML 

The configuration XML follows along similar 
lines. However, it is much shorter and so in prin- 
ciple could be directly output from the code that 
produced the configuration. Below is an example 
configuration XML ID. Again we start with a set 
of namespace declarations, which whilst the de- 
fault namespace for configuration is separate from 
that of the ensemble, it still follows the same pat- 
tern. 

The management section is very similar to that 
of the ensemble, however, there is an important 
addition: there is a "zeroth" revision which is 
generate. There is important metadata of when 
the gauge configuration was generated, and not 
just when it is submitted to the ILDG catalogue. 
As noted above ILDG middleware will eventu- 
ally create the management part of the metadata 
when it is added to the ILDG catalogue, but this 
has yet to be written. The second important dif- 
ference between the ensemble and configuration 
metadata is the <crcCheckSum/> which can be 
used to verify the data has been copied correctly. 

<?xml version="1.0" encoding="UTF-8"?> 
<gaugeConf iguration 

xmlns="http : / /www. Iqcd. org/ildg/QCDml/ 
#configl.l" 

xmlns : xsi="littp : //www . w3 . org/2001/ 
#XMLSchema-instance" 
xsi : schemaLocation="http : / / 
#www. Iqcd. org/ ildg/QCDml/conf igl . 1 
www . ph . ed . ac . uk/ ukqcd/community/ 
#the_grid/C!CDmll . 1/QCDmll . IConf ig.xsd"> 
<maiiagement> 

<revisions>l</revisions> 



<crcCheckSum> 

2632843688 
</ crcClieckSum> 
<archiveHistory> 
<elein> 

<revision>0</revision> 
<revisionAction> 

generate 
</revisionAction> 
<participaiit> 

<neime>Chris Mayneird</name> 
<institution> 

Edinburgh 
</institution> 
</participcint> 
<date> 

1998-04-24T10:25:52Z 
</date> 
</elem> 
<elein> 

<revision>l</revision> 
<revisionAction> 
add 

</revisionAction> 
<participant> 

<ncime>Chris Maynard</naine> 
<institution> 

University of Edinburgh 
</institution> 
< /part i c ipant > 
<date> 

2002-04-24T10 : 25 : 52Z 
</date> 
</eleiii> 
</archiveHistory> 
</maiiagement> 
<implementation> 
<machine> 

<name>T3E-900</name> 
<institution> 

epcc Edinburgh 
</ institution> 
<machineType> 

Alpha processor 
</machineType> 
</machine> 
<code> 
<naine> 
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UKQCD FORTRAN 
</name> 

<version>16 .8.3. l</version> 
<date> 

1997-04-04T16:20:10Z 
</date> 
</ code> 
</ implemeiitation> 
<algorithm> 
<paraineters> 

<name>targetResidue</naine> 
<value>le-07</value> 
</parcmieters> 
</ algorithm> 

<precision>single</precision> 
<markovStep> 

<markovChainURI>www . Iqcd . org/ 
#ildg/ukqcd/ukqcdl</markovCliainURI> 
<series>l</ series> 
<update>010170</update> 
<avePlaquette> 

0.53380336E+00 
</avePlaquette> 
<dataLFN> 

D52C202K3500U010170 
</dataLFN> 
</markovStep> 
</gaugeConf iguration> 

The next element is <implementation/> which 
holds information such as code versions, and ma- 
chine version. Both of these entries are really only 
important for bug tracking, but if ever a bug is 
found then they are vital for tracking down the 
effected configurations. This metadata section is 
best written by the code that generated the con- 
figuration, as it is quite easy for this metadata to 
become lost. 

The <algorithm/> element is the same as that 
of the ensemble, e.g. a name value pair for 
each algorithmic parameter that is specific to 
that configuration. The <precision/> element 
is also algorithmic in nature, it is the precision 
in which the configuration was computed, not in 
which the data is stored. It is an enumeration 
of {single , double , mixed}, it is possible to have 
some parts of gauge configuration generation code 
in single precision and some in double. 



The final segment markovStep is the most im- 
mediately useful. <markovChainURI/> is the URI 
of the Markov Chain to which this configuration 
belongs. This links the ensemble and the con- 
figuration XML IDs together. <series/> and 
<update/> locate the configuration in the Markov 
Chain. The average Plaquette is useful for check- 
ing that downloads, copies or data reads have all 
worked correctly, not least as this metadata is 
data format independent. Finally <dataLFN/> 
is the logical filename of the data on the grid. 
This links the metadata to the data. In QCDgrid 
(UKQCD's data grid) the data submission tool 
reads this element from the metadata and then 
uses this as the logical file name. 

This tutorial hopefully gives a fiavour of how to 
mark up gauge configurations in QCDmll.l. The 
ILDG website contains more detailed documenta- 
tion on the schema along with example XML IDs. 
The website will be updated regularly as changes 
and extensions occur, but this should still serve 
as a guide. 

3. FUTURE PROGRESS 

The MDWG along with the middleware work- 
ing group is actively considering the issue of data 
and file formats, but this is discussed elsewhere. 
Completing the hierarchy tree for all commonly 
used actions is another task to be finished. Gauge 
configurations are not the only data that could 
be shared by ILDG members, for instance quark 
propagators and hadron correlator. The MDWG 
is considering how to extend QCDml to such data. 
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